home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12849 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: hypatia.pec.co.nz!JohnM
  2. From: JohnM@hypatia.pec.co.nz (John Marshall)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: 22 Mar 1996 01:00:13 GMT
  6. Organization: PEC (NZ) Ltd.
  7. Message-ID: <4isu2t$opo@janus.pec.co.nz>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu> <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net> <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net> <314EBD08.43BC@virtus.com> <4io2i7$n9v@sam.inforamp.net>
  9. Reply-To: johnm@pec.co.nz
  10. NNTP-Posting-Host: hypatia.pec.co.nz
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Randy Charles Morin (rmorin@inforamp.net) wrote:
  14. >>>         -access functions are to be inline.
  15. >>>         This is the biggest fallacy in programming today.  If you make your
  16. >>> accessors inline, then you have defeated the purpose of data hiding.  If 
  17. >>> your data's type changes, then you still have to recompile every object 
  18. >>> that accesses the member.
  19. >>
  20. >> Agreed.
  21. > Thank you.  I have a hard time convincing anybody of this.
  22.  
  23. I think you have a hard time convincing anybody of this because it's
  24. not true.  It seems to me that "data hiding" has to do with the actual
  25. *text* of clients' source code, and that recompilation is merely an
  26. implementation detail.
  27.  
  28. If we had really defeated the purpose of data hiding, the statement
  29. would be: "if your data's type changes, then you have to rewrite all the
  30. clients".  This is not the case when accessors are functions which just
  31. happen to be inline.
  32.  
  33. Of course, in practice, all that recompilation during development is a
  34. major pain.  I guess that's why people put what are going to be inline
  35. accessors in library.inc, and include library.inc in either library.cpp
  36. or (for inlining) library.hpp, dependant on whether it's a "dev make" or
  37. "production make" respectively.  Certainly they're implementation -- they
  38. don't *belong* directly in the header file.
  39.  
  40. Seems to me that the fundamental problem is that include files are
  41. inherently broken compared to more automatic ways of managing the required
  42. information.  Alas.
  43.  
  44. -- 
  45. John Marshall    <johnm@pec.co.nz>
  46. PEC (NZ) Ltd, Marton, New Zealand.
  47.